home *** CD-ROM | disk | FTP | other *** search
Text File | 1988-12-15 | 4.2 KB | 85 lines | [TEXT/pdos] |
- Apple II
- Technical Notes
- _____________________________________________________________________________
- Developer Technical Support
-
-
- UniDisk 3.5
- #5: Architectural Differences Between 3.5" Drives
-
- Revised by: Matt Deatherage November 1988
- Written by: Cameron Birse & Mike Askins October 1986
-
- This Technical Note provides information of interest to those developers
- writing low-level software for the UniDisk 3.5 and Apple 3.5 disk drives.
- _____________________________________________________________________________
-
- Definition of Drives
-
- It is important to understand the differences between Apple's 3.5" drives if
- you are considering writing low-level software for use on the Apple II family
- drives.
-
- UniDisk 3.5 is an intelligent drive, meaning that it has a
- microprocessor-based controller inside the drive enclosure
- that communicates with the host computer in an intelligent
- fashion through the IWM port. The host sends commands to
- the intelligent controller in the drive and the controller
- manipulates the drive hardware to read or write, and sends
- the data back to the host in a "packet" format.
-
- Apple 3.5 Drive is an unintelligent drive that depends on the host
- computer to manipulate the drive hardware to read and write
- data to and from the drive. Apple IIGS low-level routines
- for this drive will be essentially the same as those
- downloaded to the UniDisk 3.5 controller RAM, except they
- will reside in the host computer's memory. New device-
- specific control calls must be used for the Apple 3.5 Drive.
-
-
- Tips for Low-Level Drive Access
-
- The following calls are not guaranteed to be compatible in the future; for the
- highest level of compatibility, avoid disk access at this level.
-
- o Identifying the drives: The drives can be identified by first
- searching for a device that has the SmartPort firmware. After
- determining that there is a SmartPort device in the machine,
- perform a STATUS call with the statcode = $03 (return Device
- Information Block (DIB)). In the DIB there is a type byte and a
- subtype byte. The UniDisk 3.5 has a value of $01 for the type
- byte and $00 for the subtype byte. The Apple 3.5 Drive also has a
- value of $01 for the type byte, but its subtype byte value is $C0.
- Be sure to make device-specific calls to ensure drive
- identification. See SmartPort Technical Note #7, SmartPort
- Subtype Codes for more details.
- o Special routines: In the UniDisk 3.5, there is extra RAM space
- in the controller's memory map for custom read, write and ID
- routines. These routines can be downloaded to the controller from
- the host and executed via the SmartPort. With the Apple 3.5
- Drive, these special routines reside in the host memory.
- Equivalent mark and hook tables for the Apple 3.5 Drive, set by
- control calls through the SmartPort, are supported on the Apple
- IIGS , but are not guaranteed for all drives and CPUs.
- o IWM hardware differences: On the UniDisk 3.5, the IWM
- registers are located in the drive's controller memory starting at
- $0A00. On the Apple 3.5 Drive, the IWM registers are located in
- host memory starting at $C0E0 (slot 6 I/O space).
- o Speed differences: Downloaded code in the UniDisk 3.5
- controller runs at slightly under 2 MHz, and the cycle times are
- regular. The Apple IIGS running at 1 MHz also has regular cycles,
- however, when running at 2.8 MHz, the timing is complicated by RAM
- refresh and I/O synchronization times. It is best to avoid timing
- critical solutions, or be sure to run at 1 MHz for the Apple 3.5
- Drive.
-
- As always, in order to promote compatibility between your software and future
- Apple II systems and to avoid writing utilities which will only work on one
- kind of drive, you should avoid low-level calls that are specific to a
- particular device or CPU.
-
-
- Further Reference
- o Apple IIGS Firmware Reference
-
-